1. Field of the Invention
The present invention generally relates to a method for processing session information of a session initiation protocol system and a recorded medium thereof.
2. Description of the Related Art
The Session Initiation Protocol (SIP) is an IETF standard protocol for initiating an interactive user session that involves multimedia elements such as video, voice, chat, gaming, and virtual reality. Like HTTP (Hypertext Transfer Protocol) or SMTP (Simple Mail Transfer Protocol), SIP works in the Application layer of the Open Systems Interconnection (OSI) communications model. The Application layer is the level responsible for ensuring that communication is possible.
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.
SIP can establish multimedia sessions or Internet telephony calls, and modify, or terminate them. The protocol can also invite participants to unicast or multicast sessions that do not necessarily involve an initiator. Because the SIP supports name mapping and redirection services, it makes it possible for users to initiate and receive communications and services from any location, and for networks to identify the users where ever they are. SIP is a request-response protocol, dealing with requests from clients and responses from servers. Participants are identified by SIP URLs (Universal Resource Locators) and/or SIP URIs (Universal Resource Identifiers). Requests can be sent through any transport protocol, such as UDP (User Datagram Protocol), SCTP (Stream Control Transmission Protocol), or TCP (Transmission Control Protocol). SIP determines the end system to be used for the session, the communication media and media parameters, and the called party's desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles call transfer and termination.
The SIP used when generating, modifying, and completing multimedia sessions or calls between more than one terminal on an Internet protocol-based network is an application layer control protocol, and such sessions include multimedia conference, Internet telephone call, remote education, etc.
The SIP has been modeled on the basis of SMTP, e-mail, HTTP, and the web, among others. The SIP can be called a client-server protocol for sending a response by a server when a client sends a request message.
In general, in the client/server programming model, a server is a program that awaits and fulfills requests from client programs in the same or other computers. A given application in a computer may function as a client with requests for services from other programs and also as a server of requests from other programs. Although the client/server idea can be used by programs within a single computer, it is a more important idea in a network. In a network, the client/server model provides a convenient way to interconnect programs that are distributed efficiently across different locations. Specific to the Web, a Web server is the computer program (housed in a computer) that serves requested HTML pages or files. A Web client is the requesting program associated with the user. The Web browser in a personal computer is a client that requests HTML files from Web servers.
The SIP reuses syntax and semantics of HTTP in many parts including response code architecture, a message header, and the entire operation process, and carries out transactions similar to the HTTP.
In addition, unlike HTTP and SMTP, the SIP can be executed on a TCP upper or a UDP upper. The SIP provides a mechanism for securing reliability, and a UDP can multicast SIP messages. By multicasting, it is possible to perform group invitation and basic ACD (Automatic Call Distribution).
UDP is a communications protocol that offers a limited amount of service when messages are exchanged between computers in a network that uses the Internet Protocol (IP). UDP is an alternative to the Transmission Control Protocol (TCP) and, together with IP, is sometimes referred to as UDP/IP. Like the Transmission Control Protocol, UDP uses the Internet Protocol to actually get a data unit (called a datagram) from one computer to another. Unlike TCP, however, UDP does not provide the service of dividing a message into packets (datagrams) and reassembling it at the other end. Specifically, UDP doesn't provide sequencing of the packets that the data arrives in. This means that the application program that uses UDP must be able to make sure that the entire message has arrived and is in the right order. Network applications that want to save processing time because they have very small data units to exchange (and therefore very little message reassembling to do) may prefer UDP to TCP. The Trivial File Transfer Protocol (TFTP) uses UDP instead of TCP.
UDP provides two services not provided by the IP layer. It provides port numbers to help distinguish different user requests and, optionally, a checksum capability to verify that the data arrived intact.
In the Open Systems Interconnection (OSI) communication model, UDP, like TCP, is in layer 4, the Transport Layer.
First, the SIP messages will be described as follows.
The SIP messages include a request message sent to a server from a client and a response message sent to the client from the server. The SIP messages are composed of a start line, a header field, and a message body. Various header fields have information on call services, addresses, and protocol properties. The SIP request message is composed of 6 requests, or messages, such as INVITE request, ACK request, BYE request , CANCEL request, REGISTER request , and OPTIONS request.
The INVITE request is the most basic method of starting a call between the server and the client, making a user and a service participate in a session, and includes addresses of a sender and a receiver, subject of the call, priority of the call, call routing request, and desirable response properties.
A body of a request is described by an SDP (Session Description Protocol), textual syntax for describing unicast and multicast multimedia sessions. A register for sending location information to an SIP server informs the user how the SIP server maps an incoming address with an outgoing address.
The BYE request completes connections between people who participate in a conference, and the OPTIONS request has information on capability of the receiver, then the ACK request confirms message exchanges. The user agent client uses BYE request to indicate to the server that it wishes to release the call. A BYE request is forwarded like an INVITE request and may be issued by either caller or callee. A party to a call should issue a BYE request before releasing a call (“hanging up”).
The ACK request confirms that the client has received a final response to an INVITE request. (ACK request is used only with INVITE requests.)
The CANCEL request cancels a pending request, but does not affect a completed request. A request is considered completed if the server has returned a final status response.
When a receiver receives a request message, the receiver responds to the request message by an SIP response message. A response state code is similar to an HTTP/1.1 response code, but it is an expanded type, and not all HTTP/1.1 response codes are applied like that. The response state code is shown in types of 1 xx, 2 xx, 3 xx, 4 xx, 5 xx, and 6 xx.
The 1 xx(Informational) shows that it receives a request and continues to process the request. 1 xx responses are provisional, other responses are considered final. The 2 xx(Success) means that an action was successfully received, understood, and accepted. The 3 xx(Redirection) shows that another action is necessary to complete the request, and the 4 xx (Client Error) means that the request includes bad syntax or cannot be performed in the server. The 5 xx (Server Error) means that the server did not clearly process an apparently valid request, and the 6 xx (Global Error) shows that the request cannot be fulfilled at any server.
FIG. 1 illustrates OSI 7 layer models and a structure of a UDP-based SIP stack. Like shown, an SIP is defined as a upper layer of UDP included in a fourth layer of the OSI 7 layer models. Since there is no session layer corresponding to a layer 5 in an existing SIP stack, when SIP sessions should be divided in an SIP application program, contents of SIP messages received from an application layer are parsed to detect the sessions.
FIG. 2 illustrates call setup and completion procedures of a basic SIP call. Referring to FIG. 2, a method of detecting an SIP session will be described as follows.
A setup of the SIP call begins when a client (10) sends an INVITE request to a server (20). The client (10) creates a new session before a new call setup starts. When the server (20) receives the INVITE request for a new call from the client (10), it creates a new session. If it is possible to set up a normal call for the INVITE request received in the server (20) from the client (10), the server sends a 200 OK message to the client. When the client (10) transmits an ACK request to the server (20) in response to the 200 OK message, a call setup is completed. After the call setup, it is possible to have a SESSION (conversation) between the client (10) and the server (20).
A call completion procedure can begin by the client(10) or the server(20) after the call setup. After an SIP endpoint that wants to a call completion transmits a BYE request to the other party, and after the 200 OK message is received from the other party, a call is normally completed. When the SIP endpoint transmitting the BYE message receives the 200 OK message from the other party, it deletes the session. The SIP endpoint receiving the BYE message deletes the session after transmitting the 200 OK message to the other party.
The SIP server (20) can simultaneously receive call setup requests from many clients (10). Thus, it is impossible to manage sessions with only SIP message types such as the INVITE request or 200 OK message. Since the SIP messages have inherent Call-IDs for each call, the sessions are managed by using Call-ID included in the messages with the SIP message types.
However, the problems of the prior art can be largely summarized into two as follows. First, message parsing in an application layer is necessary even though only session layer information is required. Since there is no session layer in an existing SIP stack, if sessions should be divided, the application layer has to parse all SIP messages to detect the sessions.
FIG. 3 shows an SIP load distribution function in an existing router. Referring to FIG. 3, an example of requiring SIP session information only will be described as follows. In the drawing, an SIP server pool (220) is composed of many SIP servers (220a, 220b, 220n) performing the same function. When a router (330) having the SIP load distribution function receives service requests from SIP clients (110a, . . . , 110m), it distributes the service requests of the clients to the servers according to a load of the servers of the SIP server pool (220). Because the router (330) for distributing SIP load should transmit all messages received from the same clients to the same servers for the same call, SIP session management is essential.
The existing router described in FIG. 3 manages SIP sessions in the following method. If the router (330) receives SIP messages from the clients, it detects message types and Call-IDs by parsing the SIP messages. If the message types are INVITE request, the router searches whether sessions corresponding to Call-IDs included in the INVITE request exist. If the sessions do not exist, the router creates a new session, and selects a server having the lowest load among the servers of the server pool (220), then stores mapping information between the clients and the servers as session information. The mapping information stored in the sessions includes Call-IDs, SIP client IP and port, SIP server IP and port, etc. If the router receives other messages as well as the INVITE request from the clients, and sessions corresponding to Call-IDs included in the received messages exist, the router transmits all messages received from the same clients for the same call to the same servers by using the stored session information.
Session deletion in the router is performed in a moment when a 200 OK message for a BYE request is transceived to the clients or the servers. Since the 200 OK message is used as a response for a BYE request as well as a response for other SIP message such as INVITE request or CANCEL request, the router should always maintain information on whether a response for the 200 OK message is received from what kind of message. In other words, it is required to maintain history of transceived messages, and to perform session management in reference to contents of previously-transceived messages as well as present messages.
Second, the time for session matching is long.
A Call-ID general-header field uniquely identifies a particular invitation or all registrations of a particular client. Since Call-IDs included in the SIP messages are used as key values used to search sessions, time for searching the Call-IDs by parsing the messages is necessary. Furthermore, the Call-IDs should be globally unique defined to prevent collision between all clients using the same SIP service. Thus, the Call-IDs are generated in a very long string type, including a host name and a domain name, to secure global uniqueness. When searching sessions by using the Call-IDs in the long string type, it causes a problem that time for performing a string matching process becomes long.